Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@apps/commerce-api/src/main/java/com/loopers/application/product/ProductFacade.java`:
- Around line 31-37: The cache invalidation
(productCacheService.deleteListAll()) is happening inside the transactional
method createProduct (and similarly in the update/delete methods around lines
87-101), causing a race where other requests can repopulate stale cache before
the DB commit; move the cache deletion to run after commit by registering a
post-commit callback (e.g., using
TransactionSynchronizationManager.registerSynchronization or an afterCommit
event listener) so that productCacheService.deleteListAll() executes only after
the transaction successfully commits and ensure the same change for the
corresponding update/delete methods.

In
`@apps/commerce-api/src/main/java/com/loopers/infrastructure/product/ProductCacheService.java`:
- Around line 115-121: deleteListAll currently calls
masterRedisTemplate.keys(LIST_KEY_PREFIX + "*") which uses Redis KEYS (O(N)) and
will block under write load; replace this with a non-blocking strategy:
preferred — implement an O(1) versioning scheme by adding a LIST_VERSION_KEY
(e.g., "product:list:version") and update cache key composition to include the
version (so ProductCacheService and any code that reads/writes product list
cache incorporate the version), then change deleteListAll() to simply increment
the LIST_VERSION_KEY via masterRedisTemplate.increment(...) to invalidate all
list entries; alternatively, if you cannot change key composition now, replace
the KEYS call with a SCAN-based batched delete using Redis SCAN cursor and
deleting retrieved key batches via masterRedisTemplate.delete(batch) to avoid
blocking, and add a load test for thousands of keys to ensure no CPU spikes.
- Around line 32-43: ProductCacheService currently reads with
defaultRedisTemplate (configured REPLICA_PREFERRED) while writes use
masterRedisTemplate, which can return stale values after a write; change the
cache read paths in ProductCacheService to use masterRedisTemplate for
operations that require immediate consistency (e.g.,
getProductById/getProductList) or implement a read-after-write pattern using a
versioned namespace/key (increment a version on write and read using that
version) to guarantee fresh reads; update references to
defaultRedisTemplate/masterRedisTemplate in the class and ensure
RedisConfig.REDIS_TEMPLATE_MASTER qualifier is used for reads, and add an
integration test that updates a product then immediately reads it to assert no
stale value is returned.

In `@scripts/add-indexes.sql`:
- Around line 20-22: Add a composite index for brand + createdAt so
brand-filtered queries sorted by createdAt can use an index: create an index on
(brand_id, created_at) in scripts/add-indexes.sql, then run EXPLAIN on the
brand-filter + createdAt DESC page query used by ProductFacade (default sort
createdAt DESC) and ProductRepositoryImpl (brand filter logic) to verify the
planner uses the new idx; ensure the index name is descriptive (e.g.,
idx_products_brand_created_at) and confirm EXPLAIN shows index usage rather than
filesort/extra scan.

In `@scripts/seed-data.sql`:
- Around line 70-71: 생성 스크립트가 created_at과 updated_at을 독립적으로 랜덤 생성해(updated_at이
created_at보다 과거가 될 수 있음) 문제이니, 먼저 created_at을 생성(예: DATE_SUB(NOW(), INTERVAL
FLOOR(RAND()*365) DAY) using created_at)한 다음 updated_at을 created_at보다 같거나 최신이
되도록 파생시키세요 (예: updated_at := created_at + INTERVAL FLOOR(RAND()*X) DAY 또는
GREATEST(created_at, DATE_SUB(...))). 적용 대상 식은 현재 파일의 DATE_SUB(NOW(), INTERVAL
FLOOR(RAND() * 365) DAY) 표현을 사용하는 삽입/VALUES 로직과 관련 있으며, 또한 데이터 적재 후 검증 쿼리(SELECT
COUNT(*) FROM ... WHERE updated_at < created_at)를 추가해 위 조건을 위반하는 레코드가 0인지 확인하도록
하세요.

---

Outside diff comments:
In
`@apps/commerce-api/src/main/java/com/loopers/application/like/LikeFacade.java`:
- Around line 45-60: The cache invalidation calls (productCacheService.delete
and productCacheService.deleteListAll) in addLike and removeLike run inside the
transaction and must be executed after commit; change the implementation to
register an after-commit hook (e.g.,
TransactionSynchronizationManager.registerSynchronization(...).afterCommit or
use an `@TransactionalEventListener`(phase = AFTER_COMMIT) event) so that
likeService.addLike/removeLike and
productService.increaseLikesCount/decreaseLikesCount execute inside the
transaction and the productCacheService.delete/productCacheService.deleteListAll
calls are invoked only after successful commit; ensure you reference
addLike/removeLike methods and move cache deletion logic into the after-commit
callback or event listener accordingly.

---

Nitpick comments:
In
`@apps/commerce-api/src/main/java/com/loopers/application/product/ProductFacade.java`:
- Around line 55-67: Normalize the incoming sort value once and use that
normalized value for both the cache key lookup and the DB query: call
resolveSort(sort) (or a new helper normalizeSort) to produce a canonical sort
string (e.g., mapping null/empty/unsupported to the default) and pass that
normalizedSort into productCacheService.getList(...) and into
PageRequest.of(...); update getProducts (and the analogous code around the later
block referenced at 82-83) to use the same normalizedSort for cache and
PageRequest to avoid divergent Redis keys.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@apps/commerce-api/src/main/java/com/loopers/infrastructure/product/ProductCacheService.java`:
- Around line 57-59: Update the catch blocks in ProductCacheService so the
exception object is logged instead of only e.getMessage(): replace log.warn("...
error: {}", ..., e.getMessage()) with a log.warn("... error while accessing
cache for {}: ", identifier, e) (for all six occurrences handling individual
product and list get/save/delete) to preserve the cause/stacktrace; then add
unit tests that simulate JsonMappingException and a Redis connection failure to
assert the methods return Optional.empty() and that the log contains the
exception stacktrace (i.e., verify logging captured the throwable) for the
methods involved (ProductCacheService's product/list get/save/delete handlers).
- Around line 121-129: The scan usage in ProductCacheService (ScanOptions +
masterRedisTemplate.scan(...)) leaks Redis connections because the Cursor isn't
closed and it loads all keys into memory before deleting; change deleteListAll()
to wrap the Cursor returned by masterRedisTemplate.scan(options) in a
try-with-resources to ensure closure, accumulate keys into a small fixed-size
batch (e.g., 1000) and call masterRedisTemplate.delete(batch) repeatedly rather
than collecting all keys into one List, and add a load test that exercises
deleteListAll() with large key counts (e.g., 100k) to measure memory and
latency.

---

Duplicate comments:
In
`@apps/commerce-api/src/main/java/com/loopers/infrastructure/product/ProductCacheService.java`:
- Around line 35-37: ProductCacheService currently reads from replica via
defaultRedisTemplate in get()/getList(), which can return stale data immediately
after an invalidate; change those reads to use masterRedisTemplate (or otherwise
include a versioned namespace in keys for get()/getList() to guarantee
read-after-write) so invalidation is effective, update all occurrences of
defaultRedisTemplate.opsForValue().get in ProductCacheService to
masterRedisTemplate.opsForValue().get (or switch key composition to include a
version token for list/detail keys), and add an integration test that
deletes/updates a cache entry then immediately reads to assert stale values are
not returned.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@scripts/add-indexes.sql`:
- Around line 21-24: The current index set in scripts/add-indexes.sql doesn't
cover queries from ProductRepositoryImpl.findProducts() when brandId == null (it
calls findAllByDeletedAtIsNull(pageable)), so add single-column indexes for
price and likes_count (e.g., idx_products_price on price and idx_products_likes
on likes_count) to support ORDER BY price and ORDER BY likes_count without brand
filter; also make all CREATE INDEX statements idempotent by using CREATE INDEX
IF NOT EXISTS (or equivalent conditional creation) so re-running the script
won't fail if an index already exists.

---

Nitpick comments:
In `@scripts/add-indexes.sql`:
- Around line 21-24: The CREATE INDEX statements for idx_products_brand_likes,
idx_products_brand_price, idx_products_created_at, and
idx_products_brand_created must be made idempotent to avoid errors on re-run;
update the script to use a safe path for both MySQL 8.0+ and older versions: for
MySQL 8.0+, replace each CREATE INDEX with CREATE INDEX IF NOT EXISTS ... (or
the engine-specific equivalent), and for MySQL 5.7 implement a conditional check
against information_schema (or drop the index if exists then recreate) before
running CREATE INDEX; apply these changes to the four index definitions so
re-running the script won’t fail.
- Line 21: The composite index idx_products_brand_likes on products(brand_id,
likes_count) causes index maintenance on every LikeFacade.addLike()/removeLike()
and will harm hot-path writes from ProductJpaRepository.incrementLikesCount();
either remove likes_count from the index (keep index on brand_id only) or
replace the synchronous counter update with an asynchronous/append-only counter
(e.g., separate likes_counter table, Redis counter with periodic flush, or
background aggregation) and update queries that relied on the composite ordering
accordingly; additionally add monitoring for Handler_write, p99 like latency,
and InnoDB buffer pool hit ratio to the deployment runbook to detect
regressions.